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Abstract 

Constraint Handling Rules (CHRs) are a high-level rule-based programming language for 
specification and implementation of constraint solvers. CHR manipulates a global store 
representing a flat conjunction of constraints. By default, CHR does not support goals with 
a more complex propositional structure including disjunction, negation, etc., or CHR re- 
lies on the host system to provide such features. In this paper we introduce Satisfiability 
Modulo Constraint Handling Rules (SMCHR): a tight integration of CHR with a modern 
Boolean Satisfiability (SAT) solver for quantifier-free formulae with an arbitrary propo- 
sitional structure. SMCHR is essentially a Satisfiability Modulo Theories (SMT) solver 
where the theory T is implemented in CHR. The execution algorithm of SMCHR is based 
on lazy clause generation, where a new clause for the SAT solver is generated whenever a 
rule is applied. We shall also explore the practical aspects of building an SMCHR system, 
including extending a "built-in" constraint solver supporting equality with unification and 
justifications. 

This paper is accepted for publication in Theory and Practice of Logic Programming. 
KEYWORDS: CHR, satisfiability modulo theories, lazy clause generation 



1 Introduction 



Constraint Handling Rules (CHRs) (Fruhwirth 1998) are a high-level rule-based 



programming language for the specification and implementation of constraint solvers. 
CHR has two main types of rules: simplification rules (H ■<=>• B) rewrite constraints 
H to B, and propagation rules {H ==>■ B) propagate (i.e. add) constraints B for 
every H. Constraint solvers are specified by sets of rules. 

Example 1 {Bounds Propagation Solver) 

A bounds propagation solver propagates constraints of the form X > L and X < U 
for constants L (lower bound) and U (upper bound). We can specify how bounds 
are propagated through an addition plus(X,Y, Z) constraint (i.e. X = Y + Z) via 
the following rules 

plus(X, Y, Z) A Y > L Y A Z > L z X > (L Y + L z ) 
plus{X, Y, Z) AY < U Y A Z < U z => X < (Uy + U z ) 
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Thus given the constraints plus (A, B, C), B > 3, B < 10, C > 4, and C < 6, the 
rules will propagate A > 7 and A < 16. We can similarly write rules to propagate 
bounds in other directions. □ 

The execution algorithm for CHR is based on constraint rewriting and propaga- 
tion over a global store of constraints. CHR solvers are incremental: when a new 
constraint c is asserted, we check c and the store against the rules to find a match. If 
there is a match, we apply the rule, possibly generating new constraints. Otherwise 
c is inserted into the global store. Operational semantics and execution algorithms 



for CHR have been extensively studied (Duck et al. 2004 ) ( Sneyers et al. 2010) 



The global store represents a fiat conjunction of constraints. CHR does not, 
by default, support goals that are formulae with a more complex propositional 
structure, e.g. with disjunction, negation, etc. Solving CHR constraints in other 
propositional contexts typically relies on some external machinery. For example, 



Prolog CHR implementations such as K.U.Leuven CHR system (Schrijvers and 



Demoen 2004) use Prolog's default backtracking search to handle disjunction. 

In this paper we take a different approach: we extend CHR with a Boolean Sat- 
isfiability (SAT) solver to form Satisfiability Modulo Constraint Handling Rules 
(SMCHR). The basic idea is that we specify constraint solvers using CHR in the 
usual way, such as the rules in Example [I] SMCHR goals are then quantifier-free 
formulae of CHR constraints over any arbitrary propositional context. 

Example 2 {SMCHR Goal) 

For example, the following SMCHR goal encodes the classic n-queens problem for 
the instance n = 2. 

(Qi = 1 V Qx = 2) A (Q a = 1 V Q 2 = 2) A 
-.(Qi = Q 2 ) A -.(Q! = Q 2 + 1) A -.(Q a = Qi + 1) 

This goal can be evaluated using an extended version of the bounds propagation 
solver from Example [T] For n = 2 the goal is unsatisfiable. □ 

Furthermore by integrating CHR with a modern implementation of SAT, we inherit 
all the advantages of no-good clause learning, non-chronological back-jumping, unit 
propagation, etc. 

SMCHR is essentially a Satisfiability Modulo Theory (SMT) solver, where the 
theory solver T is implemented with CHR. SMT solvers have applications such 
as program verification, program analysis, model checking, theorem proving, con- 



straint programming, etc. (Moura and Bj0rner 2011). Most SMT solvers support 



a fixed set of first-order theories, such as linear arithmetic over the reals, arrays, 
uninterpreted functions, etc. SMCHR is much more flexible, as we can support any 
theory implementable in CHR. 

Integrating CHR with a SAT solver presents several challenges. The first is the 
communication between the CHR and SAT solver engines. For this we use a gener- 



alization of lazy clause generation ( Ohrimenko et al. 2009 ) , a technique previously 



used to integrate SAT and finite domain solvers with impressive results. Another 
challenge is CHR's ability to "extend" existing built-in solvers, usually a solver 
for equality. For example, given the rule {neq(X,X) •<=>■ false) and the constraint 
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neq(A,B), the CHR solver must ask the built-in solver whether constraint A = B 
holds, and if so, apply the rule. This is particularly challenging in the context of 
SMCHR as wc wish to support both unification, efficient variable indexing, and jus- 
tifications for clause generation. A "justification" is a description of why the given 
constraint holds. 

We make the following contributions in this paper. 

- Section [3] defines the SMCHR language and logical/operational semantics; 

- Section H describes DPLL(CHR): the SMCHR execution algorithm based on 
DPLL and (lazy) clause generation; 

- Section [5] describes an SMCHR runtime system based on a new variable rep- 
resentation supporting variable indexing; 

- Section [6] describes a "built-in" reified equality solver supporting unification 
and justification; and 

- Section[7]we run experiments to evaluate our SMCHR runtime system against 
an existing CHR implementation. 



2 Preliminaries 



Constraint Handling Rules (CHR) (Friihwirth 1998) have three types of rules 



H B (simplification) 
H =>■ B (propagation) 
Hi \ H2 •<=>■ B (simpagation) 

where the head H, Hi, Hi, and body B are conjunctions of constraints. Simplifi- 
cation rules replace constraints matching H with B. Propagations rules add con- 
straints B whenever constraints matching H are found. Simpagation rules are a 
hybrid between simplification and propagation rules, where matching H2 is re- 
placed by B whenever matching Hi is found. The body B may also contain built-in 
constraints such as true and equality x — y. Extended CHR also includes guards 
for checking built-in constraints during rule matching. 

The logical semantics [_R] of a given rule R is defined as follows. 

\H <=> B} = V(i? O B) 
{H=>B}= V(H -> B) 
\Hi \H 2 ^B}= V(Hi AH 2 ^HiAB) 

where VF represents the universal closure of F. Here we assume vars(B) C vars(H). 



3 The SMCHR System 

3.1 The SMCHR Language 

The SMCHR language is the same as standard CHR with some minor differences. 
Constraint solvers are specified in terms of rules in the usual way. However, unlike 
CHR, SMCHR rules can handle both constraints and their negations. 
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Example 3 (Less-than Solver in SMCHR) 

Consider the following CHR solver that defines a "less-than" constraint lt(X,Y). 

lt(X,X) false (reflexivity) 

lt(X, Y) A lt(Y, X) => false (antisymmetry) 
lt(X, Y) A lt(Y, Z) lt(X, Z) (transitivity) 

The rules (reflexivity), (antisymmetry), and (transitivity) respectively encode the 
properties (VX : ^X < X), (VX, Y : ^X < Y V -Y < X), and (VX,Y,Z : X < 
Y AY < Z -> X < Z). With SMCHR we can also write rules that propagate 
negated constraints, e.g. 

lt(X,Y) ->lt(Y,X) (antisymmetry (2)) 

Likewise we can write rules that match negated constraints. 

->lt(X, Z) A lt(X, Y) -,lt(Y,Z) (transitivity (2)) 

->lt(X,Z)Alt(Y,Z) => ->lt(X,Y) (transitivity (3)) □ 

We extend the logical semantics of CHR in the obvious way allowing for negation. 
Under the logical semantics the rules (antisymmetry) and (antisymmetry (2)) are 
equivalent. Likewise rules (transitivity), (transitivity (2)), and (transitivity (3)) are 
also equivalent. However these rules are not operationally equivalent. 

Adding negation is not a significant extension of CHR. In fact, negation can 
already be encoded in standard CHR, e.g. by introducing a new constraint symbol: 

notJt(X, Z) A lt(X, Y) => notJt(Y, Z) 

The difference is that with SMCHR it is understood that -<c(x) is the negation of 
c(x) and vice versa. We also express CHR rules in reified-notation. This expresses 
positive literals c(x) as (true O c(x)), and negative literals ^c(x) as (false o c(x)). 
For example, rule (transitivity (2)) can be written as 

(false O lt(X, Z)) A (true lt(X, Y)) =^ (false lt(Y, Z)) 

Reified-notation will be used later for matching reified constraints. 
Other key differences between CHR and SMCHR include: 

- Range- Restricted: We assume all SMCHR rules are range restricted, i.e. for 
rule head H and body B we have that vars(B) C vars(H). 

- Set-Semantics and Negation: SMCHR assumes at most one copy of a con- 
straint can appear in the store at once. This is equivalent to assuming the 
following rules are "built-in" for each constraint symbol c: 

c(x) \ c(x) true and c(x) A ^c(x) =^> false 

- Head-Connectiveness: For all rules R with head H, for all h e H let H' = 
H — {h}, then if H' ^ we require vars(h) n vars(H') ^ 0. That is, for all 
multi-headed rules, every head constraint must share at least one variable 
with another head constraint. 
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Like SMT, SMCHR operates on quantifier- free formulae. Range- Restricted CHR 
programs ensure that no new (existentially quantified) variables are ever intro- 
duced by rule application. SMCHR with quantification is a possible direction for 
future work. Set-Semantics allows each constraint c(x) to be associated with ex- 
actly one propositional variable b. This simplifies the design of the SMCHR system. 
Head-Connectiveness ensures that constraints can be matched against rules using 
variable indexing techniques. This will be discussed further in Section|5] The Head- 
Connectiveness requirement is specific to our SMCHR implementation, rather than 
a requirement in general. 

In our experience, most CHR programs that implement constraint solvers satisfy 
the above conditions. 



3.2 The SMCHR Operational Semantics: cu s 

The SMCHR operational semantics are an extension of the theoretical operational 



semantics u>t of CHR (Duck et al. 2004) (Fruhwirth 1998). An execution state 



(G, S, B, T) is a 4-tuple consisting of a goal G, a constraint store S, a built-in con- 
straint store B, and a propagation history T. A reified constraint is of the form 
(b o c) where b is a propositional variable. Both G and S are sets of reified con- 
straints, B is a conjunction of built-in constraints, and T is a set of tuples of the 
form (r,b\, ..,b n ) where r is a rule identifier, and b\,..,b n are propositional vari- 
ables. We assume the existence of a built-in solver V that supports Boolean and 
equality constraints. 

Given an initial quantifier-free formula Go, let normalize(Go) = Gq A Gq be 
a normalized formula such that (1) Gq is a propositional formula, (2) Gq is a 
conjunction of reified constraints of the form (bi •<->• c\) A .. A (b n <-> c n ), where each 
propositional variable bi is unique, and (3) Go is equisatisfiable to Gq AG§, i.e. Go 
is satisfiablc iff Gq AGq is satisfiable. Then the initial state for Go is {Gq-, 0, Gq , 0). 
An exact definition of normalize is left to the implementation, provided the above 
conditions are preserved. 

We define isSet(B, b) to hold iff V \= B b or V \= B -> -»&. Our SMCHR 
operational semantics ui s introduces a Decide transition that sets a propositional 
variable to either true or false. The w s semantics are defined as follows: 

1. Decide: (G, S, B, T) >-» (G, S, B A (b -B- t),T) where b £ vars(B) is a propo- 
sitional variable, t € {true, false} is a propositional constant, and b is not 
already set, i.e. ^isSet(B, b). 

2. Solve: ({(b o c)} l±l G, S, B, T) ^ (G, S, {b o c) A B, T) where c is a built-in 
constraint. 

3. Introduce: ({(& o c)} W G, 5, 5, T) ^ (G, {(6 O c)} U 5, B, T) where c is a 
CHR constraint. 

4. Apply: (G, Gi W G 2 W 5, 5, T) « (£W G, Gi yS,MA B, {i} U T) where there 
exists a reified-notation rule R — (r @ Hi \ H 2 -D) and a matching substi- 
tution 9 such that = C\, 6.H 2 = G 2 , and (T> |= £? — > ^^^^fl); and 
for D = {ti^ di) A .. A (t m <-> rf m ) we have that -E = {(^ <H> 0.di), .., (6^ «-» 
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9.d m )} and M = (b' t «-> t\) A .. A (b' m «-> i m ) for fresh propositional variables 
&i,..,6' TO . Finally i = (r, 61, .., b n ) where Ci tfcl C 2 = {(61 <-> _),..,(&„ <-» _)}, 
and t <£ T. 

A failed state occurs when the built-in store B is unsatisfiable, i.e. T> |= V^P. A 
final state o> is either a failed state, or a state where no u s transition is applicable. 

Given a goal G with initial state 07, SMCHR answers UNSAT iff (1) for all 
derivations 07 ^* ap where a> is a final state then <tf is also a failed state, and 
(2) there are no non-terminating derivations 07 >— >* ... In other words: all possible 
derivations for 07 result in failure. Otherwise the answer is UNKNOWN and a non- 
failed final state ap is the result, or we simply fail to terminate. 

Theorem 1 (Soundness) 

If the answer for goal G is UNSAT, then G is unsatisfiable, i.e. [Pj,2? |= V^G. 
Proof 

(Sketch). By contradiction. Assume there exists a satisfiable goal G with answer 
UNSAT. Since G is satisfiable then normalize(G) = Gq /\G§ is also satisfiable. There 
must therefore exist a substitution 9b over the propositional variables vars(G$) 
such that 9b-G b = true and 9b-Gq is satisfiable. Consider the derivation 

U! = (Gq, 0, Gf , 0) (G* 0, 6*b A G<f , 0) = o\ 

comprised of only Decide transitions. Next consider a derivation a\ ^* ap from 
a J to a failed state ap. Such a derivation must exist, otherwise the answer for G 
cannot be UNSAT. Since the propositional variables wars(G^) are already set, the 
derivation a\ ^* ap cannot contain a Decide transition. 

The remainder of the proof is to show that each of the Solve, Introduce, and 
Apply transitions preserve satisfiability, as with standard CHR. Therefore if 07 
is satisfiable, then so is ap, and therefore ap cannot be a failed state. This is a 
contradiction, and therefore the answer for a satisfiable G cannot be UNSAT. □ 

The interpretation of UNKNOWN is merely the inability to prove unsatisfiabil- 
ity. An incomplete solver may answer UNKNOWN for unsatisfiable goals, i.e. the 
converse of Theorem [T] does not hold in general. 

Example 4 (Incomplete Solver) 

For example, consider the CHR program P 

p <^=> q p => false 

and the goal p. The goal p is unsatisfiable since [P] , V \= -*p, yet the answer for p 
is UNKNOWN because of the non-failed derivation ({b o p}, 0,6,0) (0, {b 1 ^ 
q},bAb',<D). □ 

A complete solver has the property that UNKNOWN = SAT. The result ap may be 
mapped to a solution for G depending on the definition of normalize. 
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dpllCHR(S) 

while 3b £ S. Vars : ^isSet(fo) 
I = selectLiteral(S') 
S := setLiteral(S, I) 
S. Level := S. Level + 1 
S :— propagate(S) 
if £ S. Clauses 

S = backtrack^) 
if S. Level = 

return UN SAT 
return UN KNOWN (S) 

propagate(S') 

S := unitPropagate(S') 
let 5" := S 
S :— chrPropagate(S) 
if S' = S return S 
return propagate(S') 



Fig. 1: Pseudo-code for the DPLL(CHR) algorithm. 

4 DPLL(CHR): The SMCHR Execution Algorithm 

The abstract operational semantics does not specify how and when the Decide 
transition is applied. For this we use a variant of the Davis-Putnam-Logemann- 
Loveland (DPLL) decision procedure for prepositional formulae combined with 
CHR solving, i.e. DPLL(CHR). 

The pseudo-code is shown in Figure [TJ Search is controlled by the dpllCHR(S') 
routine. Here £ represents the SMCHR "state" which includes 

- S. Vars is the set of all propositional variables; 

- S. Clauses is the a set of all clauses; 

- S. Level is the decision level; 

The state S also includes S. Trail for backtracking, and S. Store which contains the 
reified CHR constraint b O C corresponding to each b g S. Vars. The top-level 
loop selects a propositional literal / with selectLiteral, sets I to true with setLiteral, 
and propagates the change with propagate. Here selectLiteral typically uses some 
heuristic to determine the "best" literal to select, and setLiteral replaces all C G 
S. Clauses where C = {^1} U C with C", i.e. resolution. Propagation may result in 
the empty clause € S. Clauses indicating failure in which case we backtrack. The 
process continues until either all variables are set, and we have reached UNKNOWN, 
or we backtrack to level 0, indicating UNSAT. 

Our pseudo-code is a simplification. Our actual SMCHR implementation uses a 
modern SAT solver with no-good learning, back-jumping, etc. 

Propagation is handled by the propagate, unitPropagate, and chrPropagate rou- 
tines. First unitPropagate exhaustively propagates all unit clauses {/'} £ S. Clauses 
by setting V . Next we call chrPropagate to "wake up" any reified CHR constraint 
b <-> C where b has been set to true or false. Here we assume Rules are in reified 



unitPropagate^) 

if £ 5". Clauses 
return S 

if 31' :{l'} e S. Clauses 
S := setLitera^S 1 ,/') 
return unitPropagate(S') 

return 5* 

chrPropagate(S') 

let Cs = chrMatch(Rules , S) 
if Cs = nil return S 

S. Clauses := S. Clauses U Cs 
return S 
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notation. The chrMatch routine attempts to match (and apply) a CHR rule. This 
involves searching for a (renamed apart) rule (Hi \ H2 < ^=> D) £ Rules and sets 
of constraints C\,C-z C S. Store such that (1) for C\ t±J C2 = {61 -H> Ci(5i), ..,6 n f-> 
Cn(Sn)} and Hi \+> H2 = {ti f-> Ci(?/i), ..,£„ 4-> c„(j/„)} we have that &i has been 
set (via setLiteral) to the prepositional constant tf, and (2) there exists a matching 
substitution 9 such that 8.Ci(y~i) — Ci(xi) for each j G If such a match 6 is 

found, then 

1. We delete C2 from the store: S. Store :— S. Store — C2 

2. For the rule body D = {t[ «-» c[(zi), ..,t' m o cj„(z m )} (where each ^ is 
a propositional constant) we generate the set B of constraints defined as 
follows: 

B = {di «-> 6*.ci(zi), ..,d m <-» 6»4„(z m )} 

where each ci^ is either the propositional variable corresponding to an existing 
(di f-> #.c-(zi)) 6 S. Store, else is a fresh propositional variable. We set 
S. Store := B U S. Store and 5. Vars := {rfi, .., d m } U 5. Vars. 

3. We define the set of head literals Lh and body literals Lb as follows: 

L H = {h,.., l n } = {b t \ie l..n A ti} U I i e l..n A ->ti} 
L B = ..,l' m } = {di\i€ L.mAt'j} U {^d t \ i E LmA^} 
Finally we generate the following set of clauses: 

Cs = {Hi V .. V ->l n Vl'i) \ i£ l..m A -.isTrue(S, Z<)} 

Note that we do not generate redundant clauses, i.e. when isTrue(S', ij) holds. 
If there is no rule where Cs ^ nor a constraint is deleted, then chrMatch returns 
nil. 

The chrMatch routine is essentially standard CHR rule application except (1) we 
are matching reified constraints, and (2) we are generating clauses and constraints. 
Each generated clause is either a unit clause that implies l\ f-> true, or is the 
empty clause because l\ is already set to false, indicating failure. The propagate 
routine re-invokes unitPropagate if a rule was applied. Propagation continues until 
a fixed-point is reached or failure occurs. 

Propositional variables are never set by the CHR solver directly. Instead variables 
are set indirectly via the generated clauses. Each generated clause can be used by the 
SAT solver for future no-good learning and unit propagation. Our clause generation 



scheme is essentially a generalization of ( Ohrimenko et al. 2009 ) from finite domain 



propagation solvers to any solver specified in CHR. 
Example 5 (SMCHR Execution) 

Consider the rules (reflexivity) , (antisymmetry), and (transitivity) from Example [3] 
Suppose the initial goal G is 

(lt(A, B) V lt(B, A)) A lt(B, C) A -.Jt(A, C) 



Set- Semantics ensures there is only one choice for di 
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(1) ( true~\ 



A 6 3 A -16, 




match(5) = {H>i,-A 3 ,&4}} 



(3) [ ^61 A b 2 A 63 A -.64) 



Fig. 2: An example SMCHR execution tree. 



First we normalize G into a propositional formula in CNF and reified CHR con- 
straints as follows 

[(61 V 6 2 ) A b 3 A -64] A 61 <-> lt(A, B)Ab 2 ^ lt(B, A) A b 3 ^lt(B, C) A 64 <-> lt(A, C) 

The initial state is therefore 

S. Vars = {&i, 6 2 , 63, ^4} S. Clauses = {{bi,b 2 }, {63}, {^64}} 
S.Sfore = {(61 <-> £)), (6 2 o it(fl, A)), (63 o C*)), (64 ^> It (A, C))} 

A possible execution tree for G is shown in Figure [2j Execution proceeds as follows: 

(1) Assuming selectLiteral chooses literal b\, after unitPropagate we have that 
bi A 63 A ^64 is set. 

(2) Next chrPropagate is called. The rule (lt(X, Y)Alt(Y, Z) lt(X, Z)) matches 
with 9 = {X/A, Y/B, Z/C} and thus the clause — ifoi V ^b 3 V 64 is generated. 
This clause is empty (since ^64 is already true) and therefore we fail and 
backtrack. The global set of clauses is now 

S. Clauses = {{61, 6 2 }, {M, {"'M, {-'bi, - '^, M} 

A SAT with no-good learning would also generate {"^i}- 

(3) Next suppose selectLiteral selects the literal -^b\. After unitPropagate we have 
that -161 A 62 A 63 A —b±. No rule is applicable, and therefore we have reached 
a final state. The answer is therefore UNKNOWN with the result 

->lt(A, B) A lt(B, A) A lt(B, C) A ->lt{A, C) □ 

Another advantage of clause generation is that it completely subsumes the prop- 
agation history. In Example [5j the matching clause — 161 V ^63 V 64 sets 64 to true 
(i.e. isTrue(S', 64) holds) preventing the same rule from being applied once more on 
the same constraints. The rule will never be reapplied in other parts of the search 
tree where b\ A b 3 has been set to true and 64 is unset. In such cases unitPropagate 
will set 64 to true before chrPropagate is called, preventing the reapplication of the 
rule. 

So far we have not considered CHR extending an existing "built-in" constraint 
solver. Later in Section [6] we will discuss how to extend SMCHR with a built-in 
solver supporting equality x = y. 
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Fig. 3: Variable representation for the constraints from Example^ 



5 Implementation 

We have implemented a SMCHR runtime system based on the DPLL(CHR) design 
from Section [4] Most of the design and implementation is standard and covered 
by existing literature on SAT (Een and Srensson 2003), SMT (Nieuwenhuis et al. 



2006]), CHR ( jHolzbaur 1999[ ), and lazy clause generation ( |Ohrimenko et al. 2009[ ) 
This section will focus on aspects of the SMCHR implementation that are novel. 



5.1 Variable Indexing 



Prolog CHR implementations such as the K.U.Leuven CHR system ( Schrijvers and 



Demoen 2004) implement variable indexing using attributed variables (Holzbaur 



1999)(Holzbaur 1992 1. The basic idea is as follows: given a variable X, we attach an 
attribute to X which contains all CHR constraints that mention X. This attribute 
can then be used to efficiently find partner constraints when matching CHR rules. 

Example 6 {Attributed Variable Indexing) 

Suppose the CHR store contains the constraints It (A, B) A lt(B, C) A lt(C, D), then 
an attribute would be attached to B via the call 

put_attr(B, lt_index, [It (A, B), lt(B, C)]) 

Here lt_index is the attribute's name, and the list [lt(A, B), lt(B, C)] is the at- 
tribute's value containing all CHR constraints that mention variable B. 

Consider the rule propagation rule (lt(X,Y) A lt(Y,Z) => lt(X,Z)). Suppose 
we have matched lt(A,B) with the occurrence tt(X, Y), and we wish to find a 
partner constraint to match the occurrence lt(Y,Z). With attributed variable in- 
dexing, we call get_attr(_B, lt_index, Ls) to retrieve the attributes value Ls = 
[lt(A,B), lt(B,C)]. We simply scan Ls to find the match lt(B,C), and apply the 
rule. □ 

Our SMCHR runtime system also uses variable indexing, but does not use at- 
tributed variables. Instead our variable indexing scheme is based on PARMA- 



bindings (Taylor 1996). PARMA-bindings represent a variable A as a pointer-cycle 
through all constraints (or terms) that contain X. This is opposed to pointer- chains 
from a traditional WAM-style variable representation. A good comparison between 



WAM and PARMA variable representations can be found in (Demoen et al. 1999). 



Example 7 (Term and Variable Representation) 

The representation of the (reified version of the) constraints from Example [6] is 
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shown in Figure |J Here we assume a reified constraint b ■(-> f(x\, .., x n ) is repre- 
sented by a n+l-arity term /(&, x\, .., x n ). The term itself is represented as a vector 
containing the functor/arity pair followed by the term's arguments b,x%, ,.,x n . 

In Figure [3] the pointer-cycles are represented by the unbroken arrows. Symbols 
bi, 62, and 63 are prepositional variables handled by the SAT solver. The pointer- 
cycles for B and C are of length two because they appear in two constraints, whereas 
singleton variables A and D have a pointer-cycle length of one. □ 

A variable reference is a pointer to a cell in the pointer-cycle of a given variable. 
Given a reference R to variable X, we define the following low-level operations: 

1. var_next(i?) is a reference to the next cell in the pointer-cycle for X; 

2. var_container(i?) is the term containing the cell pointed to by R; and 

3. varJndex(i?) is the argument index (from 0) of the cell pointed to by R. 

Example 8 {Variable Operations) 

Consider Figure [3] once more. Here R and S are references to variable B, and T is 
a reference to the term representing the first It constraint. We sec that 

var_next(i?) = S var_next(5) = R var_container(i?) = T 
varJndex(i?) = 2 var_index(S') = 1 □ 

The var_next operation is simply pointer dereference, i.e. var_next(i?) = *R. 
Our implementation of var_container relies on low-level garbage collector support. 
Namely, it relies on a garbage collector that can efficiently] map interior pointers, 
i.e. pointers to inside a term such as i?, to exterior pointers, i.e. the pointer to the 
term itself such as T. We have implemented a garbage collector as part of our SM- 
CHR implementation^] Finally the varJndex operation is implemented in terms of 
var_container, and pointer arithmetic, i.e. varJndex(i?) = R — var_container(i?) — 1. 

Using these low-level operations, we can directly implement variable indexing. 

Example 9 (Variable Indexing) 

Consider the following constraints for variable B. 

bi O lt(A, B)Ab 2 ^ lt(D, B) A b 3 o lt(B, C) 

A possible variable layout for these constraints is shown in Figure [4aj Suppose that 
61 A 62 A 63 is set to true, and that we have matched b\ <-> It (A, B) with occurrence 
true <-> lt(X,Y) from the rule (lt{X,Y) A lt(Y, Z) => lt(X,Z)). To match the 
rule we must find a partner constraint of the form true o lt(B, _) using B as the 
variable index. 

The pseudo-code for the matching routine in shown in Figure |4b| The algorithm 
traverses the pointer-cycle of B. It will stop when either a match is found, or if we 
complete a full loop without finding a match. Assuming the layout from Figure |4aJ 
the match Jt routine will find the matching constraint 63 -H> lt(B, C) in the third 
iteration of the loop. □ 

2 In constant O(l) time. 

3 Other garbage c ollectors also support the mapping of interior to exterior pointers, e.g. the 
Boehm Collector ( jBoehm and Weiser 1988| with the GC_base(ptr) API call. 
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(a) Variable layout 



matchJt(i?) 

let Ro = R 
do 

let T = var_container(ii) 
let / = var_index(i?) 
let b = arg(0,T) 

if isTrue(fo) A functor(T, It, 3) A / = 1 
return T 

R := var_next(i?) 
while R^Rq 
return nil 

(b) Match pseudo-code 



Fig. 4: Matching a lt(_, B, _) constraint. 



Our variable representation is advantageous when it comes to discovering jus- 
tifications for equality, which will be discussed in Section [6] The disadvantage is 
that our variable indexing scheme does not directly allow for variables nested inside 
other terms, e.g. c(f(X,Y),Z). This is acceptable for solvers over "flat" domains 
such as integers. For other domains we may apply the flattening transformation as 
described in ( Sarna-Starosta and Schrijvers 2008). Here we flatten constraints by 
introducing new constraint symbols, e.g. c(f(X,Y),Z) becomes cf(X,Y,Z). 



5.2 Constraint Deletion 

When a simplification or simpagation rule is applied, we must delete some of the 
constraints that matched the rule head. Say we wish to delete constraint c(X), this 
can be achieved in one of two possible ways: 

1. Remove c(X) from the pointer-cycles of all X g X; or 

2. Overwrite the functor c with some "dummy" functor, say d. 

The latter destructively updates c(X) to d(X) making it invisible to future match- 
ings. The former is the more expensive operation, but keeps pointer-cycles shorter, 
which may be advantageous in the long run. 



6 A Reified Equality Solver 

Most CHR systems extend a "built-in" constraint solver that, at a minimum, sup- 



ports equality x = y. Prolog CHR systems such as (Schrijvers and Demoen 2004) 
extend Prolog's standard unification =/2 over (attributed) variables and terms. For 
SMCHR we require a built-in solver that supports reified equality constraints of the 
form b <-> (X = Y), where 6 is a propositional variable. For efficient rule matching 
using variable indexing, we wish to support variable unification. However, for clause 
generation, we must also support justifications that include equality constraints. In 
this section we describe how to implement such a solver using the variable repre- 
sentation described in Section UTTl 
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(a) Before 




(b) After 

Fig. 5: Variable representation and unification. 



6. 1 Unification 

Given an equality constraint b «-» (X = Y) where b has been set to true, then we 
must unify the representations of variables X and Y. This is handled the same way 
as with PARMA-bindings, i.e., by merging the pointer cycles for X and Y to form 
one larger cycle ( Demoen et al. 1999| ). Specifically, let T be the term representation 
of the equality constraint b f-> (X = Y); let Rx and Ry be the variable references 
to X and Y in T; and let R' x — var_next(i?x) and R' Y = var_next(i?.y), then we set 



*R X := R' Y and * R Y ■= R' : 



x 



Both updates are trailed and will be undone on backtracking. 

Example 10 {Variable Unification) 
Consider the constraints: 

bi lt(A, B)Ab 2 ^ lt{C, D)Ab 3 ^(B = C) 

The representation of these constraints is shown in Figure [5a] Here Rb and Rc are 
the references to B and C in the term representation of the equality constraint. 

Suppose 63 is set to true. Let R' B = var_next(i?s) and R' c — var_next(i?c), then 
the equality solver unifies B with C by setting *Rb ■= R' c and *Rc ■— R' B - This 
merges the pointer-cycles to form one larger cycle, as shown in Figure |5b| □ 

Note that variable unification only the updates the equality term itself. All other 
constraints remain unchanged. 

We avoid unifying two references to already-unified variables. Instead we delete 
the redundant equality constraint. In effect, our equality solver enforces the follow- 
ing CHR rule 



X = Y \ X = Y 



true 



The built-in equality solver only handles variable/variable unification. Variable/val- 
ue equality can be implemented via the rule 

X = c A X = d ==>■ false where c ^ d 
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1 b i : c i 

| B = C 

: b V; r 

(a) Unification B = C 




( a : b :< c i 
V„y 

(b) Unified A = BAC = BAB = D 



Fig. 6: Unification and justification of pointer-cycles. 



6.2 Justification 

Given two references to variables x and y, we must determine whether x and y are 
equal, and if they are, generate a justification as to why x and y are equal. 

Example 11 {Equality Justification) 

Given the rule (lt(X, Y) A lt(Y, X) false) and the constraints 

bi O lt(A, B)Ab 2 ^ lt(C, A) Ab 3 ^ {B = D) Ab 4 ^ {D = C) Abr ^ (A = E) 

suppose b\ A &2 A 63 A 64 A 65 is set to <rwe . The rule matches since V\=B = DAD = 
C — > £? = C with the corresponding justification 63 A 64. The negated justification 
is incorporated into the clause -ifei V ^62 V -163 V ^64 that is generated when the 
rule is applied. □ 

The challenge is to combine justification with unification. In Example |11[ vari- 
ables B, C, and D will already be unified as per Section |6.1| and thus share one 
combined pointer-cycle. For justifications, we must treat B, C, and D as separate 
variables. We can however make the following observation: 

Observation 1 

The term representation of a reified equality constraint b ■<-> (X = Y) remains in 
the combined pointer-cycle after unification. 



This is demonstrated in Figure [5j After the unification (in Figure 5b I , the term 



representation of 6 3 o (B = C) remains in the combined pointer-cycle. This term 
marks the point where the pointer-cycles for B and C were joined. With this infor- 
mation, we can reconstruct the original pointer-cycles before the unification. 

To help describe the algorithm for computing justifications, we introduce an 
abstraction based on the following observation about the "shape" of the combined 
pointer-cycle in Figure [5b] 

Observation 2 

The combined pointer-cycle has a "twist" in it, i.e. where it overlaps with itself to 
form a horizontal "figure-8" pattern. 

The abstract version the unification from Figure [5] is shown in Figure |6a| Vari- 
ables are represented by abstract pointer-cycles. Unifying two pointer-cycles forms 
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ask_eq(X,F) 

let X = X, S = e 
do 

if X = Y return S 
let T = var_container(X) 
let b = arg(0,T) 
if isTrue(&) A functor(T, =, 3) 
if peek(S) = b 

S := pop(S) 

else 

S := push(S, b) 
X := var_next(X) 
while X / X 
return unknown 

(a) Ask-equals with justification 

Fig. 7: Ask-equals with justification example. 

a larger pointer-cycle with a twist. The twist is merely an abstraction of the equal- 
ity term, and therefore denotes the transition between the original pointer-cycles 
from B to C and vice versa. 

Example 12 {Twists) 

Suppose A, B, C, and D are "fresh" variables with no twists, i.e. are yet to be 
unified with any other variable. Suppose that 

i)iH( J 4 = B)At 2 o(C = B)A6 3 o(B = D) 

and 6i A 62 A 63 is set to true. Variables A, B, C, and D are unified to form an 
abstract pointer-cycle with three twists as shown in Figure |6b| □ 

Equality justifications can be straightforwardly generated by traversing pointer- 
cycles and tracking twists. Consider the rule (neq(X, X) false) that implements 
a disequality constraint. Given a CHR constraint neq(A,B), the SMCHR engine 
asks the built-in equality solver whether variable references A and B are equal, and 
if so, the justification for the equality for clause generation. The pseudo-code for the 
ask-equals algorithm is shown in Figure |7a| The inputs are variable references X 
and Y. The algorithm traverses the pointer-cycle starting from X and maintains a 
stack S of twists. Each twist is represented by the propositional variable b from the 
corresponding non- redundant reified equality constraint 60 (_ = _). As we traverse 
the pointer-cycle and we encounter a twist 6, we either (1) pop b from S if the top of 
S is b (i.e. peek(5') = b), or (2) push b onto S otherwise. If Y is encountered, then 
X = Y holds and the stack S is returned. Otherwise unknown is returned. The 
justification for the equality is simply the resulting stack S — [b±, .., b n ] interpreted 
as the conjunction b± A .. A b n . 

Example 13 {Justifications) 

Consider the abstract pointer-cycle diagram from Figure [7b] and the variable refer- 



t 




(b) Justification example 
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Fig. 8: SMCHR vs. K. U. Leuven CHR (SWI) experimental results 



ences r, u to A, s to B, and t to D, then 

(query) (sequence) (justification) 

ask_eq(r, s) push(6 1 ), push(& 2 ), pop(& 2 ) &i 

ask_eq(r, t) push(bi), push(6 2 ), P°p(& 2 ), push(6 3 ) b\ A b 3 

ask_eq(r, u) push(6i), push(& 2 ), pop(& 2 ), push(6 3 ), pop(6 3 ), pop(fei) true 

ask_eq(u, r) e true 

Furthermore we see that ask_eq(i?, S) = ask_eq(S', R) for all R,S. For example, 
ask_eq(w,7-) = ask_eq(r. u) — true, as expected. □ 



We can similarly adapt the variable indexing routines such as from Figure 4b to 
generate justifications for matches using the same basic idea. 



7 Experiments 

In this section we test the SMCHR runtime system presented in this paper. We are 
yet to integrate a CHR compiler, and all CHR solvers tested in this section were 
compiled manually. All timings are on Intel i5-2500K CPU clocked at 4Ghz and 



averaged over 10 runs. We compare against the K.U. Leuven CHR system (Schri 



jvers and Demoen 2004) running on SWI Prolog (Wielemaker et al. 2012) version 
5.8.2., with debugging disabled and full CHR optimization enabled. The results are 
shown in Figure [H] Here, time is the time in milliseconds, ^clauses is the number 
of generated clauses (for SMCHR), and #fails is the number of fails/backtracks. A 
dash indicates a time exceeding 10 minutes. 

Benchmark cycle(n) is a cycle of CHR constraints p(Aq, A\) A .. Ap(A n , Aq) for 
p G {It, leq}. The It solver answers false, whereas the leq unifies all the variables Ai 
for i £ 0..n. Benchmark queens(n) finds a solution to the classic n-queens problem 
using a bounds propagation solver implemented in CHR (e.g. like Example [I]) and 
a generalization of the encoding from Example [2] Benchmark subsets(n,w) is a 
variant of the sum-of-(multi-)sets problem, where the multi-set is {10, .., 10} and is 
of size n, and v is the target value. For v — 99 there are no solutions. 
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The experimental results show that SMCHR is slower for benchmarks that do not 
use search/disjunction, such as cycle(n). This is because of overheads introduced 
by the SAT solver and clause generation. For benchmarks that use search, such as 
queens(n) and subsets(n, v), SMCHR is faster thanks to no-good learning. This 
benefit likely overwhelms any advantage gained from manual compilation. 



8 Related Work 



SMCHR is closely related to Satisfiability Modulo Theories (SMT) (Moura and 



Bj0rner 2011). The basic design is the same: a SAT solver core sets and wakes 



theory constraints which are solved using a theory solver (Nieuwenhuis et al. 2006). 



In SMCHR, the theory solver is specified in CHR. As far as we are aware, most 



SMT implementations do not use the (lazy) clause generation (Ohrimenko et al. 



2009 ) approach. Instead the theory solvers either do no propagation (i.e. merely test 
satisfiability) or the SAT core directly queries the theory solver for justifications 
on backtracking. The clause generation approach is far more flexible. It allows 
for theory propagation, and does not require any special algorithm to construct 
justifications on failure. 

SMCHR is not the first CHR system to support back-jumping and no-good learn- 
ing. CHR V (Wolf et al. 2008) is an extension of CHR that allows disjunction in the 



body of the rules, e.g. a rule for indomain for labelling might be: 

label(A) \ indomain(A, [Y\Ys]) X = Y V indomain(Jf, Ys) 

In SMCHR we do not currently support disjunction in rules, only in the initial 
goal. Disjunction in rules is an obvious direction for future work. The operational 



semantics of CHR V is an extension of the the refined operational semantics ( Duck 



et al. 2004 1 , where conflict driven back-jumping is supported by explicitly annotat- 
ing constraints with justifications. Unlike CHR V , we do not build the machinery of 
no-good learning, back-jumping, etc., into the operational semantics. Rather these 
details are left to the SAT solver. It is not clear how the CHR V implementation 
supports justifications for equality. 



9 Conclusions and Future Work 

In this paper we introduced SMCHR, the natural merger of SMT, CHR, and (lazy) 
clause generation. We presented a new CHR runtime system based on a new variable 
representation that supports both unification, and importantly, justifications. Our 
experimental results confirm that no-good clause learning is very effective at search 
space pruning, resulting in large speed-ups for some benchmarks. 

Our SMCHR runtime system has not yet been finely tuned and results from 
Section[7|can likely be improved. This is future work. We also intend to use SMCHR 
for applications such as automated program verification. 
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